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(54) Computer system haying a DSP focal bus. 

@ A computer system (40) having a peripheral 
bus (52) and a digital signal processor (DSP) 
local bus (58) interfacing to the peripheral bus 
via an extended bus interface circuit (EBIC) 
(56). The DSP local bus is configured such that 
devices, which are typically two or more DSPs, 
electrically connected to the DSP local bus may 
transfer data to other devices connected to the 
DSP local bus regardless of data transfer activi- 
ty of the peripheral bus. Moreover, as seen from 
the peripheral bus, the devices connected to the 
DSP local bus have the same arbitration level. 
However, as seen from the DSP local bus, each 
device connected to the DSP local bus has a 
unique arbitration level determined by the 
priority of the tasks executing on the respective 
devices, as determined by a DSP operating 
system. 
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The present invention relates generally to com- 
puter system architecture and, more specifically, to a 
computer system having a bus interface circuit that 
creates a digital signal processor (DSP) local bus 
from a peripheral bus that allows simultaneous data 
transfers between DSPs on the DSP local bus and 
between devices on the peripheral bus. Personal 
computer systems are well known in the art. 

Personal computer systems in general, and IBM 
Personal Computers in particular, have attained 
widespread use for providing computer power to 
many segments of today's modern society. Personal 
computers can typically be defined as a desktop, 
floor-standing, or portable microcomputer that is 
comprised of a system unit having a single central 
processing unit (CPU) and associated volatile and 
non-volatile memory, including all RAM and BIOS' 
ROM, a system monitor, a keyboard, one or more flex- 
ible diskette drives, a fixed disk storage device, and 
an optional printer. One of the distinguishing charac- 
teristics of these systems is the use of a motherboard 
or system planar to electrically connect these compo- 
nents together. These systems are designed primar- 
ily to give independent computing power to a single 
user and are inexpensively priced for purchase by in- 
dividuals or small business. Examples of such per- 
sonal computer systems are IBM's PERSONAL COM- 
PUTER AT and IBM's PERSONAL SYSTEM/2. 

In computer systems, the components communi- 
cate via electrical signals. These electrical signals are 
typically carried by electrical connections between 
the system components. Typical types of electrical 
connections include metal traces on a printed circuit 
board, vias, plated through holes, plugs, and individ- 
ual wires wrapped from pin to pin of system compo- 
nents. Typically groups of electrical signals and 
groups of electrical connections that carry the elec- 
trical signals are referred to as a "bus." Thus, a refer- 
ence to a "bus" can indicate a reference to a group of 
electrical signals, a group of electrical connections 
that carry the electrical signals, or a reference to both 
a group of electrical signals that form a protocol and 
a group of electrical connections that carry the elec- 
trical signals. Systems can be said to have a variety 
of buses. A "local bus" is a bus that is. in general, syn- 
chronous with the CPU and designed to optimize the 
performance of the CPU. Most systems also have a 
"peripheral bus," which is either synchronous or bus. 
Peripheral buses typically have a number of interface 
slots, which are connectors that allow peripheral de- 
vice cards to be pluggably connected to the peripheral 
bus. Typically the peripheral bus is interfaced to the 
system local bus with a bus interface circuit (BIC). 
The BIC interfaces between the system local bus and 
the peripheral bus, handling any differences in bus 
bandwidths, managing control of the buses between 
busmasters, etc. 

Personal computer systems are typically used to 



execute software to perform such diverse activities 
as word processing, manipulation of data via spread- 
sheets, collection and relation of data in databases, 
displays of graphics, design of electrical or mechani- 
5 cal systems using system design software, etc. 

One relatively recent use of the personal comput- 
er is that of the so-called "multimedia" system. In a 
multimedia system, the personal computer is used to 
capture, manipulate, or present information with au- 
to dio, visual, and/or simple data content, or signals for 
computer networks, while executing other software 
on the computer. For example, in a very simple mul- 
timedia system, the user of the personal computer 
could listen to music from an audio compact disk (CD) 

15 while working on a document in a spreadsheet pro- 
gram executing on the same computer. In more com- 
plex examples, the personal computer is used to pres- 
ent a real-time audio/visual presentation, such as a 
marketing presentation for a company, or is used as 

20 a server, which requires it to generate a network sig- 
nal without any intervention from the user, while an- 
other program is executing. 

Multimedia systems require large amounts of 
data to be manipulated. The large amount of data can 

25 quickly overwhelm a CPU, rendering it incapable of 
simultaneously executing major programs and gener- 
ating a complex multimedia presentation. 

One common way of reducing the overhead to 
the CPU in multimedia systems is to add a coproces- 

30 sor, such as a DSP, to the system. A DSP is typically 
a microprocessor with a reduced instruction set that 
is optimized to perform certain functions such as ana- 
log-to-digital conversion, digital-to-analog conver- 
sion, compression and decompression of digital data, 

35 performing mathematical operations, etc. Further, 
systems are typically designed so that the CPU will 
typically issue commands to the DSP, which will then 
execute the command independent of the CPU. 

DSPs are sometimes capable of being a "bus- 

40 master." As such, DSPs are capable of suspending 
the operation of the CPU and assuming control of a 
bus, such as the system local bus. Control of the bus 
is done through arbitration. Each device on a bus that 
is capable of being a busmaster is assigned an arbi- 

45 tration level. On some buses, each busmaster is as- 
signed a unique arbitration level; the CPU typically 
has the highest priority (and, therefore, is assigned 
the lowest arbitration level). On other buses, each 
busmaster will have the identical arbitration level, re- 

so fleeting the fact that each has equal priority. 

As multimedia systems have increased in com- 
plexity and more applications execute simultaneous- 
ly, it often becomes necessary to add more than one 
DSP to each system. These DSPs frequently must 

55 transfer data between one another. Furthermore, the 
DSPs are typically either all attached to the system lo- 
cal bus or are attached to the peripheral bus. Only one 
device can use a bus at any given time. Therefore, 
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when a DSP becomes busmaster and the DSP trans- 
fers data from another DSP or from a Micro Channel 
device, the system local bus or the peripheral bus and 
the system local bus are tied up, forcing the CPU to 
be idle during the transfer. Likewise, when the CPU 5 
is busmaster, the system local bus and the peripheral 
bus are tied up, forcing the DSPs to be idle during 
transfers.- 

Viewed from one aspect the present invention 
provides a computer system comprising: a central w 
processing unit having a first local bus associated 
therewith; a peripheral bus; a first bus interface circuit 
electrically connected to the first local bus and the 
peripheral bus, to interface between the first local bus 
and the peripheral bus; a second local bus; and a sec- is 
ond bus interface circuit electrically connected be- 
tween the peripheral bus and the second local bus, to 
interface between the peripheral bus and the second 
local bus. 

According to the present invention, the computer 20 
system is designed with three buses: (1) a first local 
bus, which is the system local bus, (2) a peripheral 
bus, and (3) a second local bus, which is a DSP local 
bus. The first local bus and the peripheral bus com- 
municate via a first bus interface unit The main focus 25 
of this invention is on the addition of the DSP local bus 
as an extension of the peripheral bus. Thus, although 
systems will typically comprise these three buses, the 
first local bus is described primarily to contrast the 
DSP local bus. The DSP local bus is designed for op- 30 
timal DSP performance and communicates with the 
peripheral bus via a second bus interface circuit, 
which is the extended bus interface circuit (EBIC). 

The EBIC is designed to interface between stan- 
dard peripheral buses, such as IBM's Micro Channel 35 
Architecture (MCA), and the DSP local bus without 
modification to the former. The EBIC, the DSP local 
bus, and the DSPs attached to the DSP local bus can 
be either placed on the system planar (system moth- 
erboard) or pluggably connected to the peripheral bus 40 
■ via expansion slots. 

The arbitration level scheme of the present inven- 
tion is unique. With respect to the DSP local bus, each 
DSP on the DSP local bus has a unique arbitration 
level. That is, each DSP has a unique priority value as 45 
seen from the DSP local bus. However, with respect 
to the peripheral bus, each DSP is assigned identical 
priority. More specifically, the arbitration level of the 
DSPs attached to the DSP local bus, as seen from the 
DSP local bus, is determined by a DSP operating sys- so 
tern (DSPOS), which bases the priority level of each 
DSP on the "urgency" of the task being executed on 
that DSP. Nominally, each DSP on the DSP local bus 
will have an identical priority level as the other DSPs, 
as seen from the DSP local bus; however, the DSP 55 
executing the highest priority task will have the high- 
est priority at any given time both (1) as seen from 
other DSP local bus devices and (2) once a device on 



the DSP local bus is given access to the peripheral 
bus. 

It is therefore an advantage of the present inven- 
tion to provide a computer system with a DSP local 
bus electrically connected to the peripheral bus. 

It is a further advantage of this invention to pro- 
vide a DSP local bus configured such that devices on 
the DSP local bus have unique priority levels when 
viewed from the DSP local bus and identical or vary- 
ing priority levels when viewed from the peripheral 
bus. 

In order that the invention may be fully under- 
stood preferred embodiments thereof will now be de- 
scribed, by way of example only, with reference to the 
accompanying drawings in which: 

Figure 1 is a block diagram of a generic prior art 
computer system with multiple DSPs; 
Figure 2 is a block diagram of a computer system 
having a DSP local bus in accordance with the 
present invention; and 

Figures 3 is a block diagram of an arbitration 
scheme for computer systems having a DSP local 
bus in accordance with the present invention. 
Before describing the details of the present in- 
vention, a description of a generic prior art computer 
system 10 with multiple DSPs may be helpful in un- 
derstanding the advantages of the computer system 
40 of the present invention. Reference is made, there- 
fore, to Figure 1, which shows a prior art computer 
system 10 with multiple DSPs. The typical prior art 
computer system 10 comprises a CPU 12, memory 
14, and miscellaneous circuitry 16 needed to gener- 
ate the address, data, control, and status signals (not 
shown) that make up a system local bus 18. The prior 
art computer system 1 0 further comprises a bus inter- 
face circuit 20, which generates a peripheral bus 22. 
The peripheral bus 22 typically has a number of ex- 
pansion slots (not shown) so that various I/O devices 
24 may be pluggably connected to the peripheral bus 
22. 

The prior art computer system 1 0 also comprises 
a number of digital signal processors (DSPs) either 
attached to the system local bus 18, shown at 26a- 
26b, or attached to the peripheral bus 22, shown at 
26c-26d. The computer system 10 may also have 
DSPs attached to both the system local bus 18 and 
the peripheral bus 22, shown at 26a-26d. 

The BIC 20 acts as an interface between the sys- 
tem local bus 18 and the peripheral bus 22. For ex- 
ample, if the CPU 12 transfers data to the I/O devices 
24, the BIC 20 must change the synchronous data 
along the system local bus 18 to asynchronous data 
along the peripheral bus 22. The BIC 20 may also be 
required to change bandwidth between the system lo- 
cal bus and the peripheral bus 22. For example, the 
system local bus 18 may have a bandwidth of 33 Mhz 
and the peripheral bus 22 may have a bandwidth of 
16 Mhz. 
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The BIC 20 also arbitrates between busmasters 
that want control of the system local bus 1 8 or the per- 
ipheral bus 22. For example, a device, such as DSP3 
26c, may want control over the peripheral bus 22. 
DSP3 will request control of the buses during an ar- 
bitration cycle. The BIC will determine when DSP3 
26c can have control of the buses. Once DSP3 26c, 
becomes the busmaster, the CPU 12 relinquishes 
control of the system local bus 18, the DSP3 26c 
takes control of the peripheral bus 22 and, as will be 
shown below, the system local bus 1 8, and the DSP3 
26a then performs the data transfers along the per- 
ipheral bus 22 and the system local bus 1 8 as though 
the DSP 26c is the CPU 12. 

In typical designs the peripheral bus 22 "mirrors" 
the system local bus 18 when a device attached to the 
system local bus 1 8 is the busmaster. That is, the ad- 
dress and data lines (not shown) of the peripheral bus 
22 assume the values of the corresponding address 
and data lines (not shown) of the system local bus 18. 
Likewise, the system local bus 18 mirrors the periph- 
eral bus 22 when a device attached to the peripheral 
bus 22 is the busmaster. 

Thus, when the system local bus 18 is in use, de- 
vices cannot use the peripheral bus 22. For example, 
if the CPU 12 is transferring data to DSP2 26b along 
the system local bus 18, the peripheral bus 22 mirrors 
that data and the peripheral bus 22 cannot be used to 
transfer data between, for example, DSP3 26c and 
DSP4 26d. Likewise, and critically, if DSP3 26c is 
transferring data to DSP4 26d along the peripheral 
bus 22, the CPU 12 must be idle, because the BIC 20 
causes the system local bus 18 to mirror the activity 
on the peripheral bus 22. 

In a system with multiple DSPs it may be neces- 
sary to have the DSPs 26a-26d transfer data directly 
to one another. No matter which DSPs transfer or re- 
ceive the data, while the transfer is occurring, the 
CPU 12 must be idle, because, as stated above, the 
BIC 20 causes the system local bus 18 to mirror the 
activity on the peripheral bus 22. The more the DSPs 
26a-26d transfer data between themselves, the more 
idle the CPU 12, the system local bus 18, and the per- 
ipheral bus 22 will be. System performance can be 
greatly diminished. 

Thus, in the prior art computer system 10 with 
multiple DSPs 26a-26d, any transfer between the 
DSPs 26a-26d forces the CPU 12 to be idle, which 
greatly decreases system performance. 

Moreover, even in systems where the system lo- 
cal bus 18 does not mirror the peripheral bus 22, 
DSP3 to DSP4 communications tie up the peripheral 
bus 22, preventing communication from or to any 
other device on the peripheral bus 22. The more the 
DSPs attached to the peripheral bus 22 transfer data 
between themselves, the more idle the peripheral bus 
22 will be. Again, system performance can be greatly 
diminished. 



Figure 2 shows a computer system 40 of the pres- 
ent invention. The computer system 40 of the present 
invention, like the prior art computer system 10, com- 
prises a CPU 42, memory 44, and miscellaneous cir- 

5 cuitry 46 needed to generate the address, data, con- 
trol, arbitration and status signals (not shown) that 
make up a system local bus 48. The computer system 
40 of the present invention further comprises a bus in- 
terface circuit 50, which interfaces between the sys- 

10 tern local bus 48 and a peripheral bus 52. The periph- 
eral bus 52 typically has a number of expansion slots 
(not shown) so that various I/O devices 54a-54c may 
be pluggably connected to the peripheral bus 52. The 
I/O devices are typically peripheral devices, such as 

15 SCSI cards, graphics cards, networking cards, TTLor 
relay input and output cards, logical analysis cards, 
oscilloscope cards, and other cards. Peripheral devic- 
es are characterized by being pluggably electrically 
connected to the peripheral bus 52. In addition, the 

20 same list may be system devices, which are charac- 
terized by their being electrically connected into the 
system local bus 48 or designed to be pluggably elec- 
trically connected to a system local bus connector 
(not shown). 

25 The BIC 50 and the other devices attached to the 

peripheral bus 52 generate the address, data, control, 
arbitration and status signals (not shown) that make 
up the peripheral bus 52. 

The computer system 40 of the present invention 

30 also comprises an extended bus interface circuit 
(EBIC) 56, which interfaces between the peripheral 
bus 52 and a DSP local bus 58. A number of DSPs 
60a-60d are connected to the DSP local bus 58. In 
one embodiment, these DSPs 60a-60d are tightly 

35 coupled to each other that is, they execute under a 
common DSPOS and may share the performing of 
tasks. The EBIC 56 and the other devices attached to 
the DSP local bus 58 generate the address, data, con- 
trol, arbitration and status signals (not shown in Fig- 

40 ure 2) that make up the DSP local bus 58. The com- 
puter system 40 may also have DSPs (not shown) at- 
tached to both the system local bus 48 and the per- 
ipheral bus 52; however, such DSPs are probably 
loosely coupled to each other and the DSPs 60a-60d. 

45 The DSP local bus 58 is not necessarily, but can be, 
identical in structure to the system local bus 48. In 
one embodiment of practicing the invention, the sys- 
tem local bus 48 is designed to optimize performance 
of the CPU 42. Likewise, the DSP local bus 58 is de- 

50 signed to optimize the performance of the DSPs 60a- 
60d. 

Like the BIC 20 of the computer system 10 of the 
prior art, the BIC 50 acts as an interface between the 
system local bus 48 and the peripheral bus 52. Like 
55 the BIC 20, the BIC 50 may be called to perform va- 
rious interface tasks, such as converting synchron- 
ous data to asynchronous data, and vice versa, and 
converting data from one bandwidth to another. The 



4 



7 



EP 0 654 743 A1 



8 



exact nature of the BIC 50 will depend on the specific 
nature of the system local bus 48 and the peripheral 
bus 52. 

Like the BIC 20 of the computer system 10 of the 
prior art, the BIC 50 also arbitrates between busmas- 
ters that want control of the system local bus 48 or the 
peripheral bus 52. However, adding the EBIC 56 and 
the DSP local bus 58 complicates the arbitration of 
the system 40. Arbitration will be covered more fully 
below. 

Like the prior art system 10, the peripheral bus 52 
of the system 40 of the present invention may mirror 
the system local bus 48 when a device attached to the 
system local bus 48 is the busmaster. Likewise, the 
system local bus 48 may mirror the peripheral bus 52 
when a device attached to the peripheral bus 52 is the 
busmaster. Therefore, as in the prior art system 10, 
when the system local bus 48 is in use, devices may 
not be able to use the peripheral bus 52, and vice ver- 
sa. 

In one embodiment, the details of the system lo- 
cal bus 48 are largely irrelevant. In one embodiment, 
the EBIC 56, the DSP local bus 58, and the DSPs 60a- 
60d are made into a card, which is pluggably connect- 
ed to a peripheral bus— in this case, the Micro Chan- 
nel. Thus^ while the system local bus 48 is shown to 
illustrate the benefits of the computer system 40 of 
the present invention, it is, not intended to be limiting. 

In the computer system 40 of the present inven- 
tion, data may be passed via any bus. For example, 
as in the prior art computer system 10, the CPU can 
transfer data to 1/01 54a via the system local bus 48, 
through the BIC 50, and via the peripheral bus 52. As 
another example, the CPU 42 can transfer data to 
DSP4 60d via the system local bus 48, through the 
BIC 50, via the peripheral bus 52, through the EBIC 
56, and via the DSP local bus 58. The DSPs 60a-60d 
can likewise transfer data to the CPU 42 using the re- 
verse path. A critical part of this data transfer scheme 
is the ability for the various devices to become "mas- 
ter 41 of a given bus or buses. As previously mentioned, 
the arbitration scheme will be further discussed be- 
low. 

In the system 40 of the present invention, traffic 
can occur simultaneously on the peripheral bus 52 
and the DSP local bus 58 in certain circumstances. 
Obviously, if a device on the system local bus 48 and 
a device on the DSP local bus 58 are communicating, 
then the system local bus 48, the peripheral bus 52, 
and the DSP local bus 58 will be tied up. However, if 
a device on the system local bus 48 is communicating 
with a device on the peripheral bus 52, only those two 
buses are tied up. Consequently, a device on the DSP 
local bus 58 is free to communicate with another de- 
vice on the DSP local bus 58. 

More specifically, the EBIC 56 is designed to al- 
low simultaneous transfers between devices using 
the peripheral bus 52 and devices using the DSP local 



bus 58 under certain conditions. For example, while 
1/01 54a is transferring data to I/03 54c (via the per- 
ipheral bus 52) or the CPU (via the peripheral bus 52, 
through the BIC 50, and via the system local bus 48), 
5 DSP1 60a can transfer data to any of the other DSPs 
60b-60d via the DSP local bus 58. Because tightly 
coupled DSPs may transfer massive amounts of data 
DSP-to-DSP in real time, this feature is believed to be 
critical to the effective functioning of the DSP local 
10 bus 58. 

In most systems, many devices are capable of 
taking control of the buses; however, only one device 
can have control of a bus at any given time. There- 
fore, some device on the system must determine 
is which of the many competing devices will have con- 
trol of the bus at any given time. Such a device is typ- 
ically called an "arbitration unit." Bus arbitration 
schemes typically limit the amount of time any device 
has control of the bus. For example, assuming the 
20 peripheral bus 58 is configured to meet the Micro 
Channel Architecture, the Micro Channel Architecture 
allows any one device to have control of the periph- 
eral bus 58 for a maximum of 7.8 fas. Thus, the length 
of a single "arbitration cycle," which is the maximum 
25 amount of time a device may have control of a bus 
when other devices desire control, on a peripheral 
bus implementing the Micro Channel Architecture is 
7.8 us. Each arbitration cycle, the devices that want 
control over the bus will attempt to assert control of 
30 the bus. 

The arbitration level of a device can be very im- 
portant. If two devices desire control over the same 
bus, there are numerous ways of deciding which de- 
vice will be given control. If the devices have unique 
35 arbitration levels, then the device with the highest pri- 
ority, as reflected by the arbitration level, will be given 
control over the bus, unless the fairness feature dic- 
tates otherwise. The Micro Channel is an example of 
a bus that uses prioritized busmaster control. On the 
40 other hand, if the devices have identical arbitration 
levels, then the devices have equal priority and the 
matter is not quite as simple— some form of round- 
robin or other priority scheme must be used to ach- 
ieve fair implementation of their equal priority. 
45 In addition, some buses have a "fairness fea- 

ture," which prevents a very high priority device from 
requesting and receiving control of the bus 100% of 
the time. The fairness feature essentially makes the 
high-priority device that is requesting control of the 
50 bus wait one or more arbitration cycles before receiv- 
ing control of the bus again. For example, on the Mi- 
cro Channel, a maximum of sixteen (16) devices can 
vie for control of the bus. The fairness feature en- 
sures that each device, no matter how low its priority, 
55 is given control over the bus from time to time. 

As described above, the computer system 40 of 
the present invention is designed to allow simultane- 
ous transfers between devices attached to the per- 
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iphera! bus 52 and between devices attached to the 
DSP local bus 58. It is believed that a special arbitra- 
tion scheme will facilitate the above simultaneous 
transfers, while at the same time achieving compati- 
bility with existing peripheral buses, such as the Micro 
Channel. 

All devices attached to a typical peripheral bus 52 
are considered one adapter. Therefore, from the point 
of view of normal operation of the peripheral bus 52, 
the EBIC 56 is one adapter. However, because the 
DSPs 60a-60d all communicate with devices on the 
peripheral bus 52 through the EBIC 56, the four DSPs 
60a-60d appear to be only one adapter from the point 
of view of normal operation of the peripheral bus 52. 
If the EBIC 56 is given just one arbitration level, then 
all the DSPs 60a-60d will be assigned that same 
code, because the DSPs 60a-60d can only access 
the peripheral bus through the EBIC 56. This can 
cause a problem from an arbitration standpoint. 

If devices attached to the peripheral bus 52 see 
all four DSPs 60a-60d as one adapter, the DSPs 60a- 
60d can be put into a situation whereby they are 
served one fourth as often as the other devices at- 
tached to the peripheral bus, such as various I/O de- 
vices 54a-54c. For example, assuming that 1/01 54a 
has higher priority than the EBIC 56 (and, conse- 
quently, the four DSPs 60a-60d) and supposing five 
devices»l/01 54a, DSP1 60a, DSP2 60b, DSP3 60c, 
and DSP4 60d--want constant control over the per- 
ipheral bus 52. Without a fairness feature, 1/01 54a 
would have complete control of the peripheral bus 52. 
With a fairness feature, the EBIC 56 will be given con- 
trol over the peripheral bus 52 every so often. Be- 
cause each DSP 60a-60d is assigned the same pri- 
ority level as the EBIC 56, only one DSP will be able 
to have control of the peripheral bus 52 each time the 
EBIC 56 is given control. Therefore, the devices 
might, for example, be given control of the peripheral 
bus 52 in the following order: I/Q1 , DSP1 , 1/Q1 , DSP2, 
1/01, DSP3, 1/01, DSP4, 1/01, DSP1, etc. Thus, each 
DSP 60a-60d is served one-fourth as often as the 
EBIC 56 is served and one-fourth as often as 1/01 
54a is served. Obviously, depending on the actual na- 
ture of the fairness feature, 1/01 54a may be given 
control over the peripheral bus 52 ten times for every 
time the EBIC 56 is given control. However, the na- 
ture of the problem caused by having all the DSPs 
60a-60d be assigned the same arbitration priority lev- 
el with respect to the peripheral bus 52 is clear: the 
DSPs are not given control of the peripheral bus 52 
often enough. 

The solution to this problem is to have a number 
of priority levels—one for every DSP attached to the 
DSP local bus 58-assigned to the EBIC 56. Suppose 
the same five devices desire control over the periph- 
eral bus 52, and the DSPs all have unique priority lev- 
els with respect to the peripheral bus 52. Obviously, 
the EBIC 56 is the only actual adapter directly attach- 



ed to the peripheral bus 52; however, because each 
DSP has its own priority level, each appears to be a 
virtual adapter on the peripheral bus 52, as far as ar- 
bitration is concerned. In this situation, the devices 
5 might, for example, be assigned control of the periph- 
eral bus in the following order: 1/01, DSP1, DSP2, 
DSP3, DSP4, 1/01, DSP1, etc. Obviously, depending 
on the actual nature of the fairness feature, 1/01 54a 
may be given control over the peripheral bus 52 ten 

10 times for every time the EBIC 56 is given control. 
However, the advantage is clear—each DSP 60a-60d 
appears to be an adapter on the peripheral bus 52 
and, therefore, each DSP 60a-60d is given a fair 
share of control of the peripheral bus 52. 

15 Arbitration of the DSP local bus 58 need not be 

quite as complicated. The DSPs 60a-60d can all be 
assigned arbitration levels that are logically identical. 
Some form of round-robin or other fairness scheme 
would determine which DSP 60a-60d will have con- 

20 trol of the DSP local bus 58 at any given time. 

In one embodiment, however, the arbitration lev- 
els for each DSP attached to the DSP local bus 58 are 
controlled by a DSP operating system (DSPOS), 
which bases the priority level of each DSP on the task 

25 or tasks executing on that particular DSP. The 
DSPOS is a program executing on each DSP attach- 
ed to the DSP local bus 58. Nominally, each DSP will 
have an identical priority level as the other DSPs, as 
seen from the DSP local bus; however, the DSP exe- 

30 cuttng the highest priority task will have the highest 
arbitration priority at any given time. 

A system 40 with a DSP local bus 58 is particu- 
larly well-suited to handle hard, real-time operating 
environments. In hard, real-time operating environ- 

35 ments, guaranteed results of execution of any task 
must be made available by a fixed or "hard" deadline 
or else the application requiring the result of the task 
will fail and/or any other tasks awaiting execution may 
be adversely affected. To overcome this problem, 

40 scheduling algorithms are commonly used to perform 
task execution scheduling whenever a new task is in- 
voked as an active task in a multi-tasking system. V. 
Gafni, A Model for Hard Real Time System Executive, 
pp. 69-74, IFAC Conference on Real Time Program- 

45 ming, Valencia, Spain, Copyright 1988; Henn, Feasi- 
ble Processor Allocation in a Hard Real-Time Envir- 
onment, The Journal of Real-Time Systems, Vol. 1, 
pp. 77-93, Copyright 1989, Kluwer Academic Publish- 
ers; Xu and Parnas, Scheduling Processes with Re- 

50 lease Times, Deadlines, Precedence, and Exclusion 
Relations, IEEE Transactions on Software Engineer- 
ing, Vol. 16, No. 3, March 1990, pp. 360-69; Chedow 
& Chedow, A Feasibility Test for Scheduling Tasks in 
a Distributed Hard Real-Time System, APII, Vol. 24, 

55 1990, pp. 239-52, Copyright AFCET 1990. The above 
rescheduling algorithms reschedule the tasks accord- 
ing to their priority whenever a task arrival or start or 
invocation time occurs by placing the task to be exe- 
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cuted in an execution queue or schedule with other 
tasks currently running or awaiting the opportunity to 
run. This approach amounts to conducting an order 
"N" sorting routine, where the worst case number of 
sorting iterations required depends upon the number 
of tasks currently in the execution queue. 

Thus, in hard, real-time computer systems the 
DSPOS should schedule tasks by ordering the cur- 
rently active tasks by the relative completion dead- 
lines with the earliest completion deadline having 
highest priority; Although the above references dis- 
close methods for determining the priority of tasks 
based on their respective "urgency," the complication 
of having tasks interrupted and the overhead involved 
with the resultant task switching generally costs great 
amounts of processing power and time. In particular, 
the solution offered by Gafni (A Model for a Hard Real 
Time System Executive), could easily end up using 
too much of the computer's resources rescheduling 
tasks because it requires keeping track of elapsed 
time, updating the remaining time for each task, and 
adding new tasks to the list which might cause the 
whole process to start over again. This might cause 
a hard real-time system to fail, particularly in a multi- 
media environment with many cyclical hard real-time 
tasks needing to be added to the list on an ongoing 
basis. Specifically, short execution period tasks cre- 
ate an inordinate amount of scheduling overhead. 

In addition to the above references, another 
method of determining the priority of tasks is present- 
ed in the copending application EP-A-553,588. Ac- 
cording to the invention of that application, the order 
of tasks in the queue is established by priority. Priority 
of tasks is in turn established at task completion times 
by the relative required execution deadlines. This pri- 
oritization, rather than a schedule prioritized merely 
at arrival time of the task on the basis of task starting 
time or ending times alone, is a key departure from 
the above references. Additionally, the order of the 
schedule of tasks to be executed is examined and re- 
arranged in accordance with the relative priorities of 
the tasks whenever a task execution is completed or 
whenever a new task is added to or deleted from the 
queue of tasks currently active in the multi-tasking 
system. Overhead processing at task invocation is 
eliminated in the invention by placing all active recur- 
rent tasks in an execution queue regardless of the 
task's current state of activity and by reprioritizing the 
order of execution of the tasks in the queue whenever 
a given task execution is completed. 

. Utilizing the invention in EP-A-553,588 above, 
the DSPOS would prioritize tasks by maintaining a list 
of ah tasks, whether they are running or waiting to be 
started, in a list ordered by relative priority based on 
completion time. The order of the list is examined and 
adjusted when a task completes execution or when- 
ever a brand new task is added to the system. This 
method results in a significant reduction in the sched- 



uling overhead for systems with large numbers of 
hard real-time tasks. Because the scheduling is done 
at the completion of task execution, there cannot be 
simultaneous tasks needing scheduling. In addition, 

5 the scheduling of a task may be interrupted by the 
execution of a higher priority task being executed. 
The entries in the list cause a multitude of tasks with 
the same completion deadline to execute, thereby 
simplifying and streamlining the scheduling task. 

10 A DSPOS prioritizing tasks as stated above 

would be very efficient; this kind of efficiency is crit- 
ical in such application areas as multi-media and ro- 
botics. 

Referring back to Figure 2, the DSP local bus 58 

15 is designed to optimize the DSPs' 60a-60d perfor- 
mance. For instance, the length of a standard arbitra- 
tion cycle of the DSP local bus 58 will depend on the 
typical DSP-to-DSP transfer time. No single value is 
ideal, but the exact arbitration cycle time should take 

20 many factors into account. For example, in the one 
embodiment, the DSPs 60a-60d have a transfer buf- 
fer that is 16 words deep and will transfer data be- 
tween each other via on-board direct memory access 
(DMA) controllers. Assuming that one word is trans- 

25 ferred per cycle, assuming a DSP local bus speed of 
16 Mhz, and assuming all 16 words are transferred in 
one cycle, the appropriate arbitration cycle time 
would be 1 .0 us plus any time needed to set up the 
transfers. Any more than that might waste valuable 

30 bus time and, therefore, lower the effective band- 
width of the DSP local bus 58. 

The system local bus 48 implements a concept 
called "direct hand off." In a system supporting direct 
hand off, a busmaster that is finished using a bus be- 

35 fore the end of the arbitration cycle time may pass 
control to another device. The direct hand off feature 
is closely linked to the arbitration in the local bus 48. 
Direct hand off on the system local bus 48 is control- 
led by the BIC 50, which has knowledge about those 

40 devices requesting control over the system local bus 
48. Thus, when the current busmaster relinquishes 
control of the system local bus 48 through direct hand 
off, if the BIC 50 determines that the system local bus 
48 still has time left in the current arbitration cycle, 

45 then the BIC 50 passes control of the system local 
bus to the device next in the arbitration queue. 

In one embodiment, the DSP local bus 58 sup- 
ports direct hand off. In that embodiment the DSP lo- 
cal bus supports direct hand off only to other devices 

so attached to the DSP local bus 58. Control may not be 
passed to the peripheral bus 52 or the system local 
bus 48. 

The system 40 must be designed to properly han- 
dle arbitration when a peripheral bus 52 busmaster 
55 attempts to transfer data to a device attached to the 
DSP local bus 58 when the DSP local bus 58 and the 
peripheral bus 52 are controlled by different busmas- 
ters. Several options are available. For example, if 
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I/03 54c is busmaster of the peripheral bus 52, if 
DSP1 60a is busmaster of the DSP local bus 58, and 
if I/03 54c desires to transfer data to DSP4 60d, the 
EBIC 56 can do one of several things: 

(1) The EBIC could remove control of the DSP lo- 
cal bus 58 from DSP1 60a at the end of the cur- 
rent transfer cycle and allow I/03 54c to have vir- 
tually immediate control of the DSP local bus 58. 
In this instance, DSP1 60a would be given top pri- 
ority for control of the DSP local bus 58 after I/03 
54c relinquishes control of the DSP local bus. 
While waiting for the current transfer cycle, the 
EBIC 56 will send a "not ready" signal to I/03 54c. 
The actual implementation of the "not ready" sig- 
nal will depend entirely on the exact nature of the 
peripheral bus 52. 

(2) In the alternative, the EBIC 56 could wait until 
DSP1 60a relinquishes control of the DSP local 
bus 58 or until the end of the current arbitration 
cycle. While waiting for DSP1 60a to finish, the 
EBIC 56 would send I/03 54c a signal telling I/03 
54c that the EBIC 56 is "not ready." As with alter- 
native (1), the actual implementation of the "not 
ready" signal will depend entirely on the exact na- 
ture of the peripheral bus 52. This message 
would be repeated (either constantly or intermit- 
tently, depending on the exact nature of the per- 
ipheral bus 52) until DSP1 60a relinquishes con- 
trol of the DSP local bus 58. Only then would the 
EBIC 56 grant control of the DSP local bus 58 to 
I/03 54c. 

To determine that a device attached to the periph- 
eral bus 52, such as I/03 54c in the immediately pre- 
ceding paragraph, is attempting to transfer data to 
any of the devices on the DSP local bus 58, the EBIC 
56 must monitor the destination address of the data 
being transferred by devices on the peripheral bus 52. 

Referring now to Figure 3, some details of the pri- 
oritization scheme are shown. Figure 3 is a schematic 
drawing showing an arbitration scheme based on an 
arbitration bus common to all DSPs. More specifical- 
ly, Figure 3 shows an EBIC 66 interfacing between 
the peripheral bus 52 and a DSP local bus 68. A num- 
ber of DSPs DSP1-DSPn 70a-70^ (in this case n 
DSPs) are attached to the DSP local bus 68. The ar- 
bitration scheme shown in Figure 3 is centralized. 
Figure 3 shows an EBIC 86 interfacing between the 
peripheral bus 52 and a DSP local bus 88. A number 
of DSPs DSP1-DSPn 90a-90Q (in this case n DSPs, 
where n is a positive integer greater than one) are at- 
tached to the DSP local bus 88. The DSP local bus 88 
is divided into n pair s of ar bitration signals— n bus re- 
quest signa ls BRQ1-BRQn and n bus grant signals 
BGT1-BGTn— and the remaining address, data, sta- 
tus, and control signals, shown collectively at 92. 

The EBIC 86 has a local bus arbitration control 
subcircuit (LBACS) 94, which is responsible for arbi- 
trating control of the DSP local bus 88. Likewise, 



each DSP has an arbitration control subcircuit (ACS) 
96a-960. The LBACS 94 has an arbitration cycle 
counter (not shown), which counts a predetermined 
number of cycles (of a free-running clock signal, not 

5 shown) corresponding to the predetermined arbitra- 
tion cycle time. 

The BR Q and BGT signals are TTL (or MOS) sig- 
nals. Each BRQ signal is generated by the corre- 
sponding ACS 96a-9 6Q of each DSP and received by 

10 the LBACS 94. Each BGT signal is generated by the 
LBACS 94 of the EBIC 86 and received by the corre- 
sponding ACS 96a-96^ of each DSP. 

Using the arbitration scheme shown in Figure 3 
is straightforward. Only the device having control of 

15 the DSP local bus 88 may assert voltages onto the re- 
maining DSP local bus lines 92. All devices without 
control of the DSP local bus 88 must put any drivers 
driving signals in the remaining DSP local bus lines 92 
into a high-impedance state. Assuming that the EBIC 

20 86 has initial control of the DSP local bus 88, the EBIC 
86 will drive any signals in the rema i ning D SP local 
bus lines 92. BRQI-BRQn and BGT1-BGTn all start 
in the logical ONE state. 

The LBACS 94 of the EBIC 86 arbitrates control 

25 of the DSP local bus 88. Any DSP desiring control 
ov er the DSP local bus 88 requests control by placing 
its BRQ line to a logical ZERO, which is detected by 
the LBACS 94. If only one DSP desires control, then 
the LBACS 94 will grant that DSP control of the DSP 

30 local bus 88. For example, if DS P1 90 a desires con- 
trol, then its ACS 96a will change BRQ1 from a logical 
ONE to a logical ZERO. If more than one device de- 
sir es con trol, each DSP will request control by placing 
its BRQ line to a logical ZERO. For example, if both 

35 DSP1 90a and DSP3 90 c wan t cont rol, th eir ACSs 
96a and 96c will change BRQ1 and BRQ3, respec- 
tively, from a logical ONE to a logical ZERO. Logic 
(not shown) within the LBACS 94 will decide control 
using a round-robin or other fairness scheme, or will 

40 decide control based on the current status of the 
DSPOS task priorities. The LBACS 96 will then place 
a single BGT line, corresponding to the DSP that is to 
be granted control, to the logical ZERO state. For ex- 
ample, if in both examples above, DSP1 90a is gran t- 

45 ed control of the bus, the LBACS will change BGT1 
from a logical ONE to a l ogica l ZERO. Immediately af- 
ter the LBACS 94 sets BGT1 to a logical ZERO, the 
LBACS 94 initializes and starts the arbitration cycle 
counter. T he A CS 96a of DSP1 90a will detect the 

so change in BGT1 and will assume control of the DSP 
local bus 88. DSP1 90a can relinquish contr ol of the 
DSP local bus at any time by changing BRQ1 from a 
logical ZERO to a logical ONE. 

If, at any time, the LBACS 94 must take control 

55 of the DSP local bus 88 from the DSP in control, in 
this case DSP1 90a, the L BACS merely changes the 
BGT line, in this case BGT1 , from logical ZERO to log- 
ical ONE. The DSP will immediately relinquish control 
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of the DSP local bus 88 and place all drivers driving 
the remaining DSP local bus lines 92 into the high im- 
pedance state. The LBACS 94 may change BRQ1 to 
a logical ONE for a number of reasons. For example, 
the arbitration cycle counter may have counted the 5 
number of cycles indicating that the busmaster has 
used its full arbitration cycle time, and the EBIC 86 
must allow another DSP to have control of the DSP 
local bus 88. In the alternative, possibly a device from 
the peripheral bus 52 desires control of the DSP local w 
bus 88 and the EBIC 86 is designed to remove control 
from the busmaster immediately in that situation. 

An advantage of the present invention is that it 
enables a multimedia computer system to have mul- 
tiple DSPs that do not tie up the system local bus or 15 
the peripheral bus during data transfers between 
DSPs. 

A further advantage is that it allows such commu- 
nications between DSPs without totally redesigning 
the system local bus or the peripheral bus. It allows 20 
such transfers between DSPs in a system using a 
standard peripheral bus, such as IBM's Micro Chan- 
nel Architecture (MCA). 



Claims X 

1. A computer system comprising: 

a central processing unit having a first lo- 
cal bus associated therewith; 30 
a peripheral bus; 

a first bus interface circuit electrically con- 
nected to the first local bus and the peripheral 
bus, to interface between the first local bus and 
the peripheral bus; 35 

a second local bus; and 

a second bus interface circuit electrically 
connected between the peripheral bus and the 
second local bus, to interface between the per- 
ipheral bus and the second local bus. 40 

2. A computer system as claimed in claim 1 further 
comprising: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 45 
nected to the second local bus; and 

a peripheral device electrically connected 
to the peripheral bus wherein the first and second 
bus interface circuits comprise circuitry for allow- 
ing simultaneous data transfers: so 

i. between the first digital signal processor 
and the second digital signal processor via the 
second local bus; and 

ii. between the central processing unit and the 
peripheral device via the first local bus, 55 
through the first bus interface circuit, and via 

the peripheral bus. 



3. A computer system as claimed in claim 2 further 
comprising: 

a second peripheral device electrically 
connected to the peripheral bus; 

wherein the circuitry allows simultaneous 
data transfers: 

i. between the first digital signal processor 
and the second digital signal processor via the 
second local bus; and 

ii. between the first peripheral device and the 
second peripheral device via the peripheral 
bus. 

4. A computer system as claimed in claim 1 further 
comprising: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 
nected to the second local bus; and 

a system device electrically connected to 
the first local bus; 

wherein the first and second bus interface 
circuits comprise circuitry for allowing simultane- 
ous data transfers: 

i. between the first digital signal processor 
and the second digital signal processor via the 
second local bus; and 

ii. between the central processing unit and the 
system device via the first local bus. 

5. A computer system as claimed in claim 1 further 
comprising: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 
nected to the second local bus; and 

wherein the first bus interface circuit com- 
prises circuitry for arbitrating control over the 
first local bus and the peripheral bus; 

wherein the second bus interface circuit 
comprises circuitry for arbitrating control over the 
second local bus and the peripheral bus; 

wherein the first and second digital signal 
processors have unique arbitration levels with re- 
spect to control over the peripheral bus. 

6. A computer system as claimed in claim 1 further 
comprising: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 
nected to the second local bus; and 

wherein the first bus interface circuit com- 
prises circuitry for arbitrating control over the 
first local bus and the peripheral bus; 

the second bus interface circuit comprises 
circuitry for arbitrating control over the second lo- 
cal bus and the peripheral bus; 

the first and second digital signal proces- 
sors have unique arbitration levels with respect to 
control over the first local bus. 
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7. The computer system of claim 1 further compris- 
ing: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 
nected to the second local bus; and 5 

wherein the first bus interface circuit com- 
prises circuitry for arbitrating control over the 
first local bus and the peripheral bus; 

the second bus interface circuit comprises 
circuitry for arbitrating control overthe second lo- 10 
cal bus and the peripheral bus; 

the first and second digital signal proces- 
sors have unique arbitration levels with respect to 
control over the first local bus and the peripheral 
bus. 15 

8. A computer system as claimed in claim 1 further 
comprising: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 20 
nected to the second local bus, each of the digital 
signal processors executing a task or tasks; and 

wherein the first bus interface circuit com- 
prises circuitry for arbitrating control over the 
first local bus and the peripheral bus; 25 

the second bus interface circuit comprises 
circuitry for arbitrating control overthe second lo- 
cal bus and the peripheral bus; 

the first and second digital signal proces- 
sors have unique arbitration levels, with respect 30 
to control over the second local bus, determined 
by the priority of the respective task or tasks exe- 
cuting on each of the first and second digital sig- 
nal processors; and 

the first and second digital signal proces- 35 
sors have unique arbitration levels with respect to 
control over the peripheral bus, or with respect to 
control over the first local bus, or with respect to 
control over both the first local bus and the per- 
ipheral bus. 40 

9. A computer system as claimed in claim 1 further 
comprising: 

at least a first digital signal processor and 
a second digital signal processor electrically con- 45 
nected to the second local bus; and 

wherein the first bus interface circuit com- 
prises circuitry for arbitrating control over the 
first local bus and the peripheral bus; 

the second bus interface circuit comprises 50 
circuitry for arbitrating control over the second lo- 
cal bus and the peripheral bus; 

the first digital signal processor has an 
identical arbitration level to the second digital sig- 
nal processorwith respect to control overthe sec- 55 
ond local bus; and 

the first and second digital signal proces- 
sors have unique arbitration levels with respect to 



control over the peripheral bus, or with respect to 
control over the first local bus, or with respect to 
control over both the first local bus and the per- 
ipheral bus. 

10. A computer system as claimed in claim 2 wherein 
the first and second bus interface circuits com- 
prise circuitry for arbitrating control overthe first 
and second local buses and the peripheral bus; 

the first digital signal processor has an 
identical arbitration level to the second digital sig- 
nal processorwith respect to control over the sec- 
ond local bus; and 

the first and second digital signal proces- 
sors have unique arbitration levels with respect to 
control over the first local bus and the peripheral 
bus. 

11. A computer system as claimed in claim 1 wherein 
the second local bus is associated with a second 
CPU. 
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